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This  ijs  the  report  of  the  productivity  enhancement  study 
of  the  ^BSO.'softwar  e  development  effort.  This  study  is  an 
intial  effort  to  identify  candidate  projects  for  oroauctivi- 
ty  improvements.  Me  do  not  attempt  a  detailed  analysis  of 

_ _ ,.y 

'FflSO  problems.  Instead,  we  try  to  adopt  an  overview  of  the 
organization  ar.d  its  problems  as  they  appear  to  outsiders. 

It  is  the  opinion  of  the  authors  that  FUSO  is  weli  managed 
and  that  employee  morale  is  generally  good,  but  that  the  or¬ 
ganization  faces  serious  challenges  in  lgcth  the  near  term 
and  the  long  term.  Substantial  changes  will  have  to  be  mad¬ 
ia  the  way  the  organization  does  business  to  keep  F1S0  via¬ 
ble  in  the  future. 

^The  major  recommendations  in  this  report  are: 

1.  Ff!SC  should  begin  work  on  a  Development  Tools  System 
that  will  support  computer  programming  work,  documen¬ 
tation  and  software  management.^  This  should  be  a 

/ 

unified  system  (all  parts  of  it  can  communicate  with 
other  parts)  but  not  necessarily  a  single  computer 
system. 

2.  “^The  physical  facilities  at  FBSO  are  below  the  recog¬ 

nized  standards  for  supporting  a  software  development 


operation  and  should  be  upgraded.  £L  -c 
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3.  Some  areas  cf  software  management  need  tc  be  im¬ 
proved.^  ticyHtilf-,  A  better  project  planning  and 
tracking  system  needs  to  be  put  in  place.  Generally, 
PMSO's  software  management  effort  is  well  directed. 

The  points  covered  in  this  report  are:  ^ 

1.  An  overall  view  or  the  FllSO  systems  effort. 

2.  A  discussion  of  the  type  of  productivity  enhancing 
effort  that  should  be  made. 

3.  A  proposal  for  the  installation  of  a  Development 
Tools  System  at  FtfSC. 

u.  An  outline  of  the  facilities  improvements  that  should 
be  made  to  improve  productivity  and  encourage  contin¬ 
ued  high  employee  morals. 

5.  project  estimating  techniques  ar.d  their  usefulness. 
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Chapter  1 
BACKGBOUHD 

1.1  INTRODUCTION  TO  PMSO 

The  Fleet  Material  Support  Office  is  an  unusual  Mavy  com¬ 
mand.  It  handles  a  variety  of  responsibilities  for  tne  3up- 


Corps,  but  most 

cf  its  work  is 

to 

function  as  a  Central 

;ign  Activity  for 

various  supply 

and 

financial  computer 

r.etrs.  In  effect. 

FMSO  is  the  inf 

orm 

ation  systems  arm  cf 

r3  UrSYSCCM.  The 

major  mission  ar 

-as 

for  FM30  are: 

1.  Central  Design  Agency  activities. 

2.  Management  of  the  Navy's  Retail  Stock  Fund. 

3.  operations  analysis  activities. 

4.  Supply  operations  support. 

5.  Int ernaticnal  logistics. 

The  CDA  activity  consumes  30*  of  FMSO's  resources,  and  it  is 
the  area  that  we  will  be  concerned  with  in  this  report.  The 
major  concern  of  this  study  is  to  focus  on  ways  to  increase 
the  productivity  of  the  CCA  activity. 

The  major  functions  supported  by  the  CDA  activity  are: 

1.  Uniform  Autoaated  Data  Processing  Systems  (DDAPS)  . 

a)  Uniform  ADP  System  for  Inventory  Control  Points 
(UICP)  . 

b)  OADPS  stock  Points  (UADPS-SP). 
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c)  Level  II/III  stock  Points. 

d)  Disk  Oriented  Supply  s  ystea  (3DS3)  . 

2.  Headquarters  Financial  Systems. 

3.  Management  Information  System  for  International  Lo¬ 
gistics  -  SISIL. 

4.  Special  Data  Processing  Systems  Projects. 

a)  3MM6E  -  Requisition  Material  Monitoring  and  Expe¬ 
diting. 


b) 

Triden-  logistics  data. 

=  ) 

NALCCMIS. 

d) 

SAIDS  -  Navy  Automated  Transportation 

Data  S  yst  em. 

2) 

navads  -  Navy  Automated  Transportation 

Document  a- 

ticn  S yrtera  . 

f) 

Resolicicaoion . 

g) 

SPAR. 

The  list  cf  responsibilities  placed  or.  FMSO  is  nmpressive. 

If  it  were  a  private  organization,  it  would  be  a  major  soft¬ 
ware  house  or  computer  company.  with  approximately  1,360 
employees  FMSC  has  a  staff  that  is  about  200  smaller  than 
Apple  Computer.  The  employees  charged  with  the  CD  A  activity 
have  to  maintain  a  library  of  computer  systems  consisting  cf 
approximately  10,000  -  12,000  programs  totaling  cn  the  order 
of  20  million  lines  of  cede.  In  industrial  terms,  this  sys¬ 
tem  library  is  about  what  one  would  expect  to  find  in  a  ma¬ 
jor  high  technology  company  that  employed  around  200,000 
people.  This  library  has  been  in  development  for  10  to  20 
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1.2  G§MEFA£  EBOBiENS  iT  FHSO 

Some  of  the  problems  that  beset  FKSO  would  occur  in  ar.y 
information  systems  group  in  any  organization.  Information 
systems  activity  is  generally  a  service  at-  This  means 
that  others  in  the  organization  do  not  rea  y  appreciate  the 
problems  involved  in  developing  software  have  little 

idea  about  effective  ways  of  doing  it.  Th  expect  the  ser¬ 
vice  to  be  available  when  they  want  it  and  in  the  form  that 
they  want  it.  The  result  is  that  an  information  systems 
group  can  develop  serious  problems  in  its  relations  with  its 
upper  level  management  and  its  customers.  The  group  has 
little  control  ever  planning  or  resource  allocation  for  its 
area,  but  it  tends  tc  get  blamed  fer  everything  that  gees 
wrong.  In  FMSO's  case,  this  problem  is  mai-a  worse  by  the 
fact  that  their  superiors  are  in  Washington,  and  their  major 
customers  are  spread  all  ever  the  globe.  The  reputation  of 
the  organization  suffers  as  a  consequence  even  when  its 
problems  are  not  of  i’-s  own  malting. 

Besides  these  general  sorts  of  information  systems  group 
problems,  there  is  another  set  of  problems  that  arises  for 
computing  groups  working  fer  the  government  in  general  and 
for  the  Navy  in  particular.  During  the  fifties  and  sixties. 
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computers  were  generally  recognized  as  useful,  bur  they  k?:; 
very  expansive  ar.d  difficult  re  manage.  As  a  result,  a 
whole  set  cr  regulations  grew  up  around  the  use  and  procure¬ 
ment  of  computers  with  the  Brooks  Bill  being  the  item  most 
often  cited.  The  effect  has  been  to  require  lengthy  justi¬ 
fication  for  any  computer  procurement. 

The  ircnic  thing  is  that  computers  have  gotten  much 
cheaper  since  these  regulations  k-:s  firs-  put  into  effect. 
Computer  power  that  would  have  required  a  mainframe  twenty 
years  ago  can  new  be  purchased  at  K-Mart  in  the  toy  depart¬ 
ment.  Tor  computer  systems  costing  between  310,000  *r  d 
31  00,000,  the  justif  icaticn  cf  the  system  as  one  of  the  most 
expensive  accessories  on  the  machine.  There  have  beer,  two 
side  effects  cr  this.  The  first  is  to  make  managers  reluc¬ 
tant  to  procure  equipment  even  the  ugh  it  may  be  of  consider¬ 
able  benefit  to  the  organization.  For  the  i  idividuai  manag¬ 
er,  a  trocurmer.t  effort  means  that  his  staff  is  occupied 
with  the  paperwork  required  to  purchase  a  computer  instead 
of  being  able  to  do  their  regular  jobs. 

Another  problem  that  affects  FXSO  is  the  Navy  attitude 
toward  shore  facilities.  There  seems  to  be  an  unwritten 
policy  in  the  Navy  that  the  first  priority  should  be  given 
to  the  fleet  while  shore  and  support  facilities  ate  of  sec¬ 
ondary  importance.  The  socialization  of  Naval  officers  also 
leads  them  to  accept  shore  facilities  that  are  less  than 
ideal.  Shipboard  life  involves  a  lot  of  crowding  and  dis- 
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comfort.  No  matter  how  bad  a  shore  facility  may  be,  it  is 
likely  to  be  mere  comfortable  and  spacious  than  a  shipboard 
facility.  Unfortunately  for  FMSO,  the  standard  of  compari¬ 
son  is  not  shipboard  software  development  facilities  (if 
there  were  such  a  thing) .  It  is  the  numerous  software  de¬ 
velopment  facilities  springing  up  all  around  the  Harrisburg 
area.  It  will  be  irresistable  for  FMSO  employees  to  compare 
their  working  conditions  with  those  available  at  places  like 
EDS  and  CACI. 

These  comments  apply  to  both  the  physical  plant  at  FMSO 
and  to  the  computer  systems  upon  which  development  is  done. 
The  computers  for  which  FMSO  dees  development  work  must  be 
among  the  oldest  currently  operating.  This  is  a  costly 
proposition  from  many  points  of  view.  For  the  individual 
programmer,  it  is  costly  because  he  falls  behind  techno¬ 
logically.  Computer  personnel  are  an  unusual  breed.  Of  all 
the  professions,  they  hold  professional  development  ir.  high¬ 
est  regard.  This  is  natural  considering  that  computer  tech¬ 
nology  changes  rather  quickiy,  and  that  any  individual  who 
falls  behind  is  likely  to  find  himself  out  of  a  job.  FMSO 
has  done  a  good  job  in  making  professional  development 
training  available  to  its  staff.  This  is  probably  a  major 
reason  for  the  remarkable  loyalty  to  the  organization  we  ob¬ 
served  there. 

There  are  other  problems  in  trying  to  deal  with  older 
technologies  than  just  personnel  considerations.  Both  the 
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equipment  and  design  phiiosophias  for  operating  systems  have 
changed  considerably  since  FMSO's  equipment  was  installed. 
Magnetic  tape  criented  systems  for  data  processing  are  new  a 
thing  cf  the  past.  Magnetic  tape  is  cheaper  than  disk,  but 
its  use  requires  a  great  deal  of  operator  intervention. 

There  are  too  many  chances  for  error  in  tae  use  of  tape.  In 
a  disk  oriented  system,  the  process  of  calling  files  and 
setting  up  jots  is  done  automatically  without  human  inter¬ 
vention.  The  disk  system  may  be  acre  costly  tc  install,  but 
the  elimination  cf  tape  handling  errors  makes  it  a  good  deal 
cheaper  in  the  long  run. 

The  same  is  true  of  older  operating  systems.  Such  sys¬ 
tems  generally  called  for  more  operator  intervention.  This 
oper.ed  up  more  chance  cf  error.  The  newer  philosophies  ir. 
operating  systems  call  for  "programming  the  idiot  cut  of  the 
loop"  -  that  is,  designing  the  system  so  that  it  rarely 
calls  on  humar.s  for  decisions.  A  final  point  in  the  opera¬ 
tion  of  older  systems  is  the  maintenance  problem.  As  a  sys¬ 
tem  ages,  the  manufacturer  of  the  system  becomes  less  inter¬ 
ested  in  performing  software  enhancements  and  updates.  He 
naturally  wants  to  concentrate  on  newer  products,  and  even¬ 
tually  the  software  on  the  older  system  becomes  obsolete. 

If  the  customer  does  not  upgrade  his  hardware,  he  gets  left 
behind  in  the  evolutionary  process  of  system  development. 
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1.3  EB2SU35  IB  5£A£3IBS  A  solotioi 

The  problems  mentioned  above  combine  to  sake  long  tern 

solutions  very  difficult  in  this  environment.  Acquisition 
of  r.6«  computer  systems  or  the  institution  of  long  range 
changes  can  take  years  in  the  Navy  environment.  An  example 
of  this  is  the  IC?  Resoli citation  project.  This  nas  been 
underway  for  about  eight  years  now,  and  the  first  machine 
should  come  or.  line  in  19  84  (if  all  goes  well).  This  is  an 
unconscionably  long  time  for  a  systems  change.  In  an  indus¬ 
trial  enviroment,  this  should  take  no  acre  than  a  year  with 
only  a  few  months  spent  on  the  study  portion. 

A  critic  of  F !1S3  might  argue  that  this  only  proves  that 
the  machines  were  unecessary  ir.  the  first  place  and  that#  the 
government  has  saved  itself  eight  years  of  computer  expense 
by  staying  with  the  old  equipment.  This  is  all  quits  true. . 
The  machines  are  "unnecessary"  in  the  sense  that  there  is 
always  another  way  to  do  a  computer  job.  In  this  case,  the 
computer  savings  were  generated  at  the  expense  of  personnel 
costs,  project  delays  and  degraded  service  for  the  naval 
supply  system. 

Unfortunately,  the  personnel  costs  do  not  get  charged  off 
to  specific  information  processing  systems  in  quite  the  same 
way  as  a  computer.  If  they  don’t  appear  on  anybody's  bottom 
line,  than  there  is  a  tendency  to  regard  these  costs  as  not 
being  real. 
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The  (Jnivac  495's  that  NAVSUP  uses  to  manage  the  ICP's 
were  obsolescent  when  the  system  was  installed  in  1965.  sy 
now,  they  are  hopelessly  out  of  date.  What  this  means  is 
that  because  cf  the  Navy's  "can  do"  attitude,  these  machines 
have  been  kept  going  long  past  their  useful  life.  The  price 
for  this  is  mere  operations  personnel,  time  spent  on  systems 
development  and  changes  to  the  operating  system,  and  time 
spent  fine  tuning  FMSO's  applications  to  get  the  most  possi¬ 
ble  "bang  per  buck"  out  of  a  'Jnivac  494.  There  is  little 
doubt  that  ICP's  (Jnivac  4  94's  have  beer,  tuner  so  that  they 
are  operating  more  efficiently  (where  efficiency  is  measured 
in  computer  time  only)  than  any  (Jnivac  494  's  in  history. 

Why  anyone  would  want  to  do  such  a  thing  is  another  ques¬ 
tion  . 


1  *  *»  CONCiOSICNS 

The  Commanding  Officer  cf  FMSO  faces  several  significant 
challenges.  The  organization  has  some  real  long  range  prob¬ 
lems.  These  include  systems  upgrades,  improvements  that 
need  to  be  made  to  take  advantages  of  r.ew  technologies  ar.d 
improvement  of  the  physical  environment.  The  steps  we  re¬ 
commend  to  solve  some  of  these  problems  are  going  to  gener¬ 
ate  short  range  chaos.  A  CO's  tour  of  duty  is  only  two 
years.  If  a  new  CO  came  in  and  accepted  all  of  our  recom¬ 
mendations  on  the  first  day  of  his  tour,  then  by  the  end  of 
his  tour  FMSO  would  be  in  a  such  more  disrupted  state  than 


when  he  took  over.  In  fact,  the  same  would  probably  be  “.rue 
of  his  successor,  and  it  would  act  be  until  the  third  CO  ir. 
the  sequence  than  we  would  begin  to  see  payoffs  from  some  of 
the  productivity  measures  we  will  recommend  (about  five 
years  out)  .  FMSO  is  already  engaged  in  a  number  of  steps  to 
solve  the  problem  areas  we  observed.  Things  seemed  to  be 
moving  in  positive  directions  and  the  management  was  well 
aware  of  the  challenges  facing  before  tais  report  was  writ¬ 
ten. 
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Chapter  2 

APPROACHES  IN  IMPROVING  PRODUCTIVITY 

2.  1  jMTBQPgCTjCCN 

There  are  na n y  possible  approachs  to  improving  prcductiv 
it y  in  software  development.  There  is  no  one  magic  techni¬ 
que  that  will  guarantee  results  under  ail  conditions.  The 
nest  effective  techniques  to  apply  in  improving  productivit 
will  depend  or.  the  current  status  of  the  organization,  its 
level  of  expertise,  and  the  type  of  systems  and  management 
environment  ir.  which  it  operates.  In  addition,  the  ap¬ 
proaches  to  productivity  improvement  given  in  the  literatur 
tend  tc  be  interdependent.  They  cannot  be  applied  separate 
ly  or  piecemeal  ar.d  have  any  chance  of  achieving  success. 
For  example,  medern  software  management  techniques  cannot  b 
used  effectively  in  an  antique  computing  enviroment.  Most 
of  the  productivity  improvement  techniques  are  highly  dacen 
der.t  upon  interactive  computing  environments,  sophisticated 
development  tools  and  the  ability  to  transfer  both  develop¬ 
ment  code  and  administrative  data  quickly  among  the  individ 
uals  involved  in  a  project.  On  the  other  hand,  high  tech¬ 
nology  by  itself  is  no  guarantee  of  a  productive 
environment.  A  productivity  improvement  program  needs  a 
well  thought  cut  managment  plan  combined  with  the  latest 
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■technology.  In  this  document,  we  will  try  to  lay  out  the 
aspects  of  a  productivity  enhancement  program  for  FMSO. 

2.2  PR08JJHS  IN  DEPIfilHS  PRODUCTIVITY 

The  first  problem  with  productivity  in  a  software  envi¬ 
ronment  is  deciding  what  it  is.  This  may  sound  odd  at  first 
because  everycr.e  thinks  that  they  know  what  productivity  is. 
In  a  manufacturing  environment  such  as  the  automobile  indus¬ 
try,  it  is  not  too  hard  tc  come  up  with  definitions  for  pro¬ 
ductivity.  An  automobile  is  a  tangible  item.  It  either 
works,  or  it  dees  not.  It  is  built  from  components  that  are 
easy  tc  cost  cut  and  a  cost  for  its  production  can  be  com¬ 
puted  fairly  readily. 

In  software  development,  this  is  not  the  case.  It  is 
hard  to  come  to  some  sort  of  solid  analysis  as  to  just  what 
is  oeing  produced  by  programmers.  In  cr.e  sense,  it  is  not 
too  different  from  the  case  of  an  automonile.  Programmers 
produce  programs,  and  these  programs  either  work,  or  they  dc 
not.  But  each  pregrammer  working  on  a  system  produces  only 
a  piece  of  it,  and  there  is  no  set  standard  for  measuring 
what  these  pieces  are.  The  measure  most  commonly  used  in 
industry  is  lines  of  code.  All  we  have  to  do  is  count  the 
lines  of  cede  produced  by  a  programmer,  and  divide  that  into 
the  cost  of  supporting  the  programmer,  and  we  have  a  produc¬ 
tivity  figure  that  we  can  use. 


But  when  one  begins  to  examine  both  the  published  litera¬ 
ture  and  the  possibilities  available  in  the  definition  of 
lines  of  cede,  cr.®'  s  confidence  in  this  measure  begins  tc 
slip  away.  For  instance,  what  do  you  count?  Is  every  com¬ 
ment  line  in  a  program  counted,  cr  do  we  only  count  executa¬ 
ble  code?  Do  we  count  the  lines  ir.  a  program  that  contain 
commands  tc  the  operating  system,  cr  do  we  only  worry  about 
the  source  ianguage  code?  what  do  we  do  about  code  that  has 
been  produced  for  another  system  and  has  bean  re-used  for 
the  system  that  we  are  trying  to  analyze?  Can  we  count  cede 
that  has  been  produced  by  a  program  generator?  The  list  of 
possible  questions  is  almost  endless. 

One  reply  tc  this  is  that  it  does  net  really  make  too  . 


much  difference.  All  we  have  to  dc  is  cnoose  some  reason¬ 


able  measure  and  stick  with  if.  Indeed,  this  is  what  most 
organizations  dc.  But,  this  does  make  it  hard  to  compare 
productivity  across  organizations.  It  is  not  uncommon  tc 
find  "productivity"  differences  that  are  almost  an  erder  of 
magnitude  apart  in  comparing  two  different  software  organi¬ 
zations1.  In  many  cases,  much  of  this  difference  in  produc¬ 
tivity  comes  from  differences  in  the  counting  conventions 
that  are  applied  to  computer  code.  It  would  be  a  mistake  to 
accept  these  differences  at  face  value  as  true  differences 
in  productivity. 


1  See  Barry  Boehm,  Software  Engineering  Economics,  p.  86  for 
a  table  listing  the  different  effort  models  and  a  brief 
comparison  cf  the  number  of  man-months  predicted  by  each 
for  a  software  development  project. 
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There  are  ether  possibilities  for  measuring  the  outpu-  of 
a  software  effort.  It  is  possible  to  define  the  basic  func¬ 
tions  performed  in  a  program,  and  then  count  productivity  as 
number  of  functions  implemented2.  Another  possibility  would 
be  to  count  number  of  programs  released.  Both  of  these  are 
somewhat  grosser  measures  than  lines  of  code,  and  in  their 
own  way,  they  can  be  as  hard  to  implement.  No  matter  what 
measure  is  chosen  for  productivity  in  an  organization,  care 
should  be  taken  in  its  application.  One  does  not  want  to 
come  up  with  a  measure  that  encourages  behavior  that  is 
counterproductive.  For  example,  if  one  chooses  lines  of 
code  as  a  measure  then  checks  should  be  made  from  time  to 
time  to  make  sure  that  this  is  not  encouraging  programmers 
to  use  ceding  techniques  that  maximize  lrr.es  of  cede.  simi¬ 
larly,  if  one  cheese  programs  released  as  a  measure,  then  it 
would  be  to  a  programming  team's  advantage  tc  only  try  to 
work  on  short,  simple  systems.  This  would  boost  their  "pro¬ 
ductivity"  measure  as  defined  by  the  organization.  Whatever 
measure  is  chosen,  it  should  be  applied  wind  common  sense, 
examined  frequently  and  compared  with  ocher  measures  of  pro¬ 
ductivity.  Slavish  adherence  to  ar.  inappropriate  productiv¬ 
ity  measure  could  do  more  damage  to  real  productivity  than 
not  paying  any  attention  to  productivity  at  all. 


2  For  an  example  of  this  approach,  see  the  article  by  A.  J. 
Albrecht,  "Measuring  Application  Development  Productivi¬ 
ty". 
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2.3  gHIOEIJIES  IN  IMPROVIJIG  PRODUCTIVITY 


In  improving  progr as mer  productivity  at  FMSO,  we  have  a 
few  problems  because  there  is  no  currently  accepted  defini¬ 
tion  of  productivity  in  place  at  FMSO.  This  means  that  we 
could  institute  programs  for  productivity  improvement,  but 
we  have  nc  way  c;  measuring  hew  w^ll  these  programs  perform. 
One  approach  tc  this  problem  would  be  to  set  up  some  produc¬ 
tivity  measures,  gather  data  and  use  this  data  as  a  bench¬ 
mark  for  future  productivity  enhancement  measures.  »e  feel 
that  this  weald  be  a  bad  approach.  The  problems  that  FMSO 
has  are  serious  enough,  and  the  organization  is  enough  be¬ 
hind  the  current  state  of  the  art  in  information  systems 
technology  that  we  feel  that  certain  measures  must  be  taken 
without  delay.  In  setting  up  a  productivity  improvement 
program  at  FMSC,  we  feel  that  the  following  areas  should  be 
considered  (in  order  cf  priority) : 

1.  Automation  of  the  systems  development  process. 

2.  Improvement  cf  the  physical  environment  at  FMSO. 

3.  Development  of  a  system  of  productivity  measurement 
and  data  gathering  to  support  this  system. 

4.  Development  of  a  system  for  project  planning  and 
tracking  based  on  the  productivity  measures  devel¬ 
oped. 

5.  Continue  the  work  on  a  set  of  automated  development 
tools  ir.  support  of  the  systems  development  effort. 
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All  of  these  problems  are  serious,  and  to  a  certain  ex¬ 
tent,  they  must  all  be  attacked  simultaneously.  lie  feel, 
however,  that  the  automation  of  the  software  development 
process  is  the  most  important  issue  to  be  solved  in  the  near 
term.  The  highest  priority  should  be  given  to  the  acquisi¬ 
tion  of  a  development  tools  system  to  aid  in  both  software 
development  and  project  management.  A  major  problem  at  FMSO 
is  that  development  takes  place  or.  "test  bed"  machines. 

Such  machines  are  set  up  tc  meet  the  needs  of  the  organiza¬ 
tion  for  which  the  software  is  being  developed.  They  do  not 
have  the  full  set  of  software  aids  that  one  would  expect  c.t 
a  modern  software  development  facility  (sophisticated  text 
editors,  interactive  compilers,  fils  transfer  protocols, 
message  handling  facilities,  and  word  processing  text  for¬ 
matters)  .  These  tools  are  not  necessary  for  the  ultimate 
missions  of  these  test  bed  machines.  However,  these  auto¬ 
mated  tools  are  very  effective  for  software  development  and 
project  management.  Further,  because  the  development  ma¬ 
chines  are  identical  to  the  actual  production  machines,  the 
temptation  to  pre-empt  development  activity  if  one  of  the 
production  machines  is  down  is  very  strong.  The  immediate 
needs  cf  users  naturally  have  a  higher  priority  than  long 
term  development  projects,  and  this  car.  result  in  slowdowns 
in  development.  The  "test-bed"  machines  are  actually  the 
production  machines  of  the  development  groups,  but  users 
tend  to  overlook  this.  It  must  be  recognized  that  software 
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development  is  a  highly  specialized  activity,  and  that  i- 
nesds  its  own  production  facility.  There  is  r.o  reason  why 
the  development  system  has  to  be  the  same  machine  as  the  cr.e 
for  which  the  software  is  being  developed.  In  fact,  devel¬ 
oping  the  software  on  a  different  machine  could  actually 
serve  to  make  the  code  more  readily  porta o ie . 

2.4  THE  CASE  FOR  A  DEVELOPMENT  TOOLS  SYSTEM 

The  development  tools  system  should  serve  both  management 
and  programmers.  It  is  hard  to  separate  the  needs  of  the 
programmers  and  the  protect  managers  in  a  large  software  ef¬ 
fort.  if  anything,  the  larger  the  software  effort,  the  mere 
time  and  effort  will  be  spent  in  management  and  documenta¬ 
tion  issues.  For  a  large  system,  actual  codrng  is  likely  to 
consume  about  30S  cf  the  effort.  The  remaining  effort  is 
spent  in  dccumentatic n,  management  and  coordination  of  the 
diverse  elements  making  up  the  system.  Any  development 
tools  system  iaplemented  should  be  able  to  support  these 
needs.  A  unified  development  tools  system  should  be  able  no 
support  these  functional  areas: 

1.  Development  documentation. 

2.  Project  management  and  tracking. 

3.  Budgeting. 

4.  Program  coding. 

5.  Program  testing. 

6.  Database  development  and  program  test  data. 
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7.  Quality  assurance. 

To  those  used  to  cider  generations  of  equipment,  this  may 
sound  like  an  impossible  list  of  tasks  for  a  single  coinput 
er.  In  fact,  this  list  is  the  rule  rather  than  the  excep¬ 
tion  on  modern  large  scale  computers.  Most  mainframes  off 
a  wide  variety  of  tools  that  will  support  this  type  cf  env 
rcnment. 

The  processors  needed  to  support  systems  development  ir. 
elude: 

1.  Interactive  compilers. 

2.  Languages  with  string  processing  capaoilities. 

3.  Text  processing  packages  for  formatting  documenta¬ 
tion. 

4.  Sophisticated  file  handling  capabilities. 

5.  Screen  criented  text  editors  for  manipulating  both 
cede  and  text. 

6.  The  ability  to  transfer  data  from  one  user  to  anoth 
quickly  and  conveniently.  This  would  be  used  for 
both  autenated  office  type  applications  ana  program 
men’s  work  bench. 

7.  Packages  for  doing  statistical  analysis. 

8.  A  graphics  system  fer  producing  documentation  and 
management  reports. 

9.  Automatic  typeset  facilities  for  producing  "clean” 
documentation  and  reducing  printing  costs. 
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The  idea  is  that  a  development  system  should  support  a  wide 
variety  cf  both  computer  related  and  management  related  ac¬ 
tivities.  Some  nay  object  to  the  proposal  that  text  pro¬ 
cessing  abilities  should  be  included  on  the  development  sys¬ 
tem.  The  counter  argument  would  run  -  "We  already  have  word 
processing  facilities.  why  buy  mere?".  What  we  are  propos¬ 
ing  here  is  somewhat  different  from  the  normal  word  process¬ 
ing  systems.  The  development  system  would  be  used  to  tie 
together  a  number  of  different  applications,  and  word  pro¬ 
cessing  would  be.  one  cf  them.  It  _s  very  convenient  ar.i 
cost  effective  to  oe  able  *0  do  both  programming  and  word 
processing  on  -he  same  machine.  ?cr  one  thing,  it  allows 
you  to  take  the  output  of  a  program,  reformat  it  and  use  it 
as  part  of  the  text  ir.  a  manual.  This  is  difficult  to  do  on 
an  ordinary  word  processing  system  because  rt  involves  re¬ 
entry  of  data  that  was  already  generated  by  the  computer 
anyway.  The  strategies  for  building  a  development  system 
are  discussed  in  Chapter  3. 

2.5  IMPROVISE  THE  PHYSICAL  PLANT 

Almost  as  important  as  the  acquisition  of  a  development 
tools  system  is  improvement  of  the  programming  environment 
at  FMSO.  The  present  facilities  are  inadguate  for  any  type 
of  clerical  werk,  particularly  computer  programming.  FMSO 
is  housed  in  an  old  warehouse  building.  The  space  inside 
the  building  is  broken  up  using  shoulder  height  partitions. 
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These  partitions  are  of  the  old-  fashioned  sort  that  do  net 
provide  much  sound  insulation.  The  building  itself  is  r.cisy 
and  poorly  air  conditioned.  This  is  the  worst  environment 
for  software  production  that  we  have  ever  seen. 

The  present  facilities  provide  about  50  square  feet  of 
floor  space  for  each  employee.  In  the  no  a du ter  industry, 

100  square  feet  is  considered  normal3.  Programming  is  an 
activity  that  requires  somewhat  different  types  of  office 
spaces  than  a  other  clerical  jobs.  The  by-products  of  ccm- 
p 1 - e r  programming  (listings,  sheets  cf  graphics  output,  man¬ 
ual  libraries)  take  up  a  great  deal  of  work  space  and  stor¬ 
age  space.  To  use  them  effectively  requires  specially 
designed  work  areas  and  storage  areas.  A  programmer  needs  a 
desk  for  normal  work,  a  work  table  where  he  can  spread  out 
listings  or  notes  for  work  (even  with  a  more  modern  system 
that  de-emphasizes  hardcopy,  it  will  be  a  while  before  all 
programmers  accustom  themselves  to  this)  ,  a  terminal  for  in¬ 
teraction  with  the  computer  and  storage  areas  for  listings 
and  manuals.  It  goes  without  saying  that  this  all  should  be 
in  the  context  of  a  physically  comfortable  environment.  The 
air  conditioning  should  be  adequate  to  the  climate,  and  the 
sound  insulation  should  be  good.  In  addition,  there  have  to 
be  conference  facilities  readily  available  for  meetings  cf 

3  See  the  description  of  the  IBM  Santa  Teresa  labs  which 
were  specifically  designed  to  support  software  develop¬ 
ment.  The  reference  is  G.  M.  McCue,  "IBM's  Santa  Teresa 
Laboratory  -  Architectural  Design  for  Software  Develop¬ 
ment". 


project  teams.  Program  development  for  a  large  system  is  a 


relatively  social  activity,  and  this  nesting  space  is  needed 
for  the  jot  as  well.  The  command  seems  to  be  well  aware  of 
the  space  problems  and  is  taking  steps  to  remedy  them.  Seme 
of  the  problems  will  be  alleviated  in  the  future  as  systems 
work  moves  away  from  cards  and  the  floor  space  taken  by  card 
files  can  te  reclaimed. 

The  issue  cf  programming  environment  is  an  important  one 
and  is  addressed  in  Chapter  4.  There  are  no  specific  stud¬ 
ies  relating  programming  environments  t:  productivity.  As 
we  discussed  earlier,  productivity  measures  are  rather  rub¬ 
bery,  and  it  would  be  statistically  difficult  to  relate  spe¬ 
cific  productivity  measures  to  ail  cf  the  possible  variables 
m  environmental  design.  Still,  if  your  building  layout  is 
substantially  at  variance  with  what  is  considered  normal  in 
t.ie  the  industry,  then  your  programmers  are  likely  to  no¬ 
tice.  FJ1SO  is  ringed  by  software  houses  (5DS,  CACI  and  oth¬ 
ers)  ,  and  the  program  development  environments  there  are 
likely  to  come  a  lot  closer  to  industry  norms  than  they  do 
at  Faso.  Eventually  FMSO  is  going  to  lose  many  of  its  best 
employees  to  these  organizations  because  they  perceive  a 
batter  environment  there.  It  is  a  tribute  to  the  management 
practices  in  place  at  FHSO  that  the  employee  morale  is  as 
good  as  it  is. 
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2. 6  Cg 8 CIOS ICgS 


The  observations  we  have  male  in  this  chapter  should  come 
as  no  surprise.  From  our  conversations  with  FMSO  staff, 
these  are  well  known  problems.  They  do  not  seem  no  be  wide¬ 
ly  known  outside  the  organization,  however.  We  feel  that 
PM  SO  is  at  a  crucial  point  in  its  existence.  It  has  to  ei¬ 
ther  improve  its  technical  and  physical  facilities,  or  it 
will  cease  being  a  viable  software  development  organization. 

The  options  are  either  to  improve  the  facility  or  to  abandon 
- 

The  process  of  productivity  improvement  must  be  attacked 
on  several  fronts.  The  most  important  is  the  improvement  cf 
the  technical  and  physcial  environment.  It  dees  not  make 
s^r.se  to  try  to  implement  modern  software  management  techni¬ 
ques  in  a  hors*  and  buggy  technical  environment.  The  im¬ 
proved  software  management  techniques  will  be  helpful  in  any 
environment,  but  they  will  not  be  as  effective  on  a  non'-in- 
teractive,  antique  computer  system.  Along  with  the  improve¬ 
ment  of  the  system,  an  acceptable  measure  of  productivity 
must  be  developed  and  installed.  All  of  these  changes  are 
evolutionary,  and  will  take  a  good  deal  of  time.  There  are 
no  generally  accepted  productivity  measurement  techniques  in 
industry.  The  models  used  tend  to  be  tailor  made  for  each 
organization,  and  th9  same  will  be  true  for  FMSO. 
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Chapter  3 

REQUIREMENTS  FOR  A  DEVELOPMENT  TOOLS  SYSTEM 

3. 1  iaSJS52CTION 

Since  the  Development  Tools  System  is  to  be  installed  ir. 
a  Navy  environment,  the  first  thing  to  consider  is  the  pro¬ 
curement  of  this  type  of  equipment.  To  someooay  accustomed 
to  industry  standards  for  software,  the  leal  times  for  gov¬ 
ernment  software  procurements  seem  excruciatingly  long.  The 
IT P  Reso licitaticn  effort  at  F*!SO  has  seer,  going  on  for 
eight  years  r.cw,  and  the  first  machine  has  yet  to  arrive. 

In  industry,  eight  years  would  be  the  complete  life  cycle 
for  the  system  from  the  first  feasibility  study  to  the  final 
departure  cf  the  system  at  the  end  of  its  life.  In  the 
past,  such  long  life  cycles  have  guarantied  that  the  equip¬ 
ment  will  be  ctsciete  when  installed. 

Part  of  the  problem  is  that  a  great  deal  of  economic  jus¬ 
tification  is  required  for  a  government  procurement.  There 
is  nothing  wrcng  with  this  per  se,  but  this  economic  justi- 
ficatation  is  always  tied  to  a  specific  shopping  list  of 
hardwara,  and  the  whole  thing  has  to  go  through  many  levels 
of  approval.  Meanwhile,  the  computer  industry  changes  at  a 
rapid  pace,  and  the  list  of  hardware  quickly  becomes  obosc- 
l9te.  It  would  be  worthwhile  to  consider  th9  approach  tak9n 


by  the  SPLICE  project  ir.  acquiring  a  3 
3  he  a  Id  be  cr.  the  f  jr.c*;:n«  t.u*  t  r.e  y  3 
not  cr.  tne  speciric  Its*,  c i 
Sanctions.  The  system 
bis.  Once  a  prccur-saan 
be  used  ds  a  venicii  :o 
This  is  being  cere  :r.  la*, 

the  IC?  Sesc  licita: ,  ar.  i  it  nay  re.?  to 
-he  past  prcnieis.  Tne  p  iccu  tea  er.t  iccuaent  is  regardei  as 
a  vehicle  fee  ru-ure  i?gr;ies  and  r  .3  rest  for  re- yjsr  1  r  1  ca¬ 
tion  cf  upgrades  should  te  avoided.  Tr.s  sue  s:r*  ;f  focus 
sr.ould  be  used  ir.  one  acquisition  cf  a  Javeicpaer.*.  Tods 
System. 

3.2  sa*s3isiit  s&easuiius.  n<mu2 

The  functional  capabilities  in  the  Development  Tcols  Sys¬ 
tem  should  include: 

1.  Interactive  compilers  and  debugging  tools  for  system 
development  in  the  major  languages  used  at  FMSO. 

This  would  b s  COSOL  and  perhaps  FORTRAN. 

2.  Interactive  languages  with  good  string  processing  ca¬ 
pabilities  for  use  as  tool  generating  languages. 
These  wculd  be  used  to  generate  data  bases,  and  de¬ 
velop  automated  tocls  for  analyzing  computer  code 
(structure  and  standards  checkers  would  be  two  exam¬ 
ples)  .  Good  candidate  languages  would  be  PL/I  cr 
Pascal. 
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3.  High  speed  terminals  with  full  screen  editing  capa¬ 
bility.  Ideally,  there  should  be  a  terminal  for  each 
programmer. 

4.  An  electronic  mail  system  so  that  programs,  documen¬ 
tation  and  data  could  be  routed  readily  among  the 
members  of  the  development  team.  Such  a  system  could 
serve  as  the  foundation  of  the  development  and  man¬ 
agement  work  on  FM SC  systems. 

5.  A  variety  of  management  tool  aids  such  as  statistical 
packages  (SPSS,  Hinitab),  management  packages  (PERT) 
and  rapcrt  generating  packages  (RAH IS  II  or  FOCUS)  to 
aid  in  controlling  the  development  of  FHSO  projects. 

6.  A  sophisticated  word  processing  capability  that  would 
include  the  ability  to  format  large  documents  (the 
requirements  tend  to  be  different  than  for  small  word 
processing  systems).  Examples  of  systems  of  this 
type  would  be  Script  or  AIMS. 

7.  A  sophisticated  graphics  capability  for  producing 
both  documentation  and  management  reports. 

3.  An  automatic  typesetting  system  tied  in  with  a  high 
speed  laser  printer. 

This  is  a  formidable  set  of  requirements  for  a  single  ma¬ 
chine.  A  number  cf  manufacturers  supply  equipment  that 
could  handle  these  requirements,  but  it  would  probably  be 
more  economic  to  consider  a  Local  Area  Network  (LAN)  rather 
than  to  try  to  satisfy  all  of  this  on  a  single  machine.  The 
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networking  system  chosen  would  be  the  vehicle  for  future 
system  growth.  Increments  to  this  computer  power  could  be 
added  as  needed. 

At  the  base  of  this  network,  there  would  have  to  be  one 
or  mere  reasonably  powerful  mainframe  systems.  These  would 
be  required  for  i uplament ing  programming  tools  and  for  doing 
interactive  testing  of  code.  Individual  editing  and  word 
processing  functions  could  probably  be  handled  on  smaller 
"smart"  terminals.  It  makes  more  sense  to  download  process¬ 
ing  onto  cheaper  micros  and  minis  rather  than  trying  to  find 
a  large  CPU  tc  handle  everything. 

3.3  COST  JUSTIFICATION  FOR  THE  DEVELOPMENT  TOOLS  SYSTEM 

It  will  be  difficult  tc  do  traditional  economic  analysis 
on  such  a  system  for  cost  -fustif ica tion.  The  normal  govern¬ 
ment  approach  to  economic  analysis  on  systems  is  to  deter¬ 
mine  requirements,  cost  out  a  sat  of  alternatives  for  meet¬ 
ing  those  requirements  and  then  choose  the  most  cost 
effective  alternative  for  the  system.  There  is  nothing 
wrong  with  this,  but  it  does  make  one  rather  large  assump¬ 
tion  at  the  start  -  namely  that  you  can  determine  your  "re¬ 
quirements".  In  FMSO's  case,  this  will  simply  not  be  true. 
The  software  development  environment  there  is  so  far  behind 
current  technology  that  the  programmers  could  not  even  state 
exactly  how  they  will  use  the  new  system.  Our  experience  at 
NPS  is  probably  instructive.  Before  we  acquired  our  IBM 
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30  33  AP  system,  we  went  through  the  standard  justification 
and  benchmarking  based  on  the  best  guesses  we  could  come  up 
with  on  how  users  would  use  the  new  machine.  These  guesses 
proved  to  be  totally  inadequate  because  our  users  were  very 
quick  to  come  up  with  unanticipated  uses  of  the  machine. 

This  is  the  problem  of  trying  to  assess  "unmet  demand"  in 
advance.  In  FMSO's  case,  the  problem  is  likely  to  be  an  or¬ 
der  of  magnitude  worse  because  the  systems  in  place  there 
are  so  old.  It  will  taka  the  programmers  at  least  a  year 
before  they  begin  to  feel  comfortable  with  the  machine. 

Once  they  do  feel  comfortable  with  it,  they  will  begin  tc 
use  it  ir.  ways  that  are  hard  to  anticipate.  A  LAN  type 
technology  will  at  least  alio*  you  to  expand  ycur  resources 
ir.  a  modular  fashion. 

3.4  CONCLUSIONS 

FSSO  should  try  to  remain  as  flexible  as  possible  in  its 
acquisition  of  a  Development  Tools  System.  Fortunately, 
this  is  relatively  easy  to  do  with  newer  computer  systems. 

It  is  possible  tc  buy  a  system  as  a  set  of  building  blocks 
and  integrate  and  expand  the  system  over  time  by  adding  new 
pieces.  Paso  and  the  Navy  generally  need  to  change  the  way 
they  think  about  computer  systems.  A  computer  system  is  not 
a  solution  to  a  problem.  This  type  of  thinking  leads  plan¬ 
ners  to  believe  that  a  particular  system  is  good  now  and 
forever.  A  computer  system  is  a  part  of  a  problem  solving 
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process.  As  the  process  changes,  it  is  probably  a  good  idea 
to  consider  changing  the  system  as  well.  NAVsUPSiCSCOh  has 
failed  to  do  this  with  its  computer  systems,  and  it  will  be 
a  difficult,  expensive  process  to  upgrade. 

Newer  trends  in  Navy  procurement  make  it  easier  to  ac¬ 
quire  useful  computer  systems  by  fccusir.g  on  the  functions 
provided  by  the  system  rather  than  on  a  snooping  list  of 
computcr  hardware.  FMSO  needs  to  look  at  developing  an  in¬ 
tegrated  system  that  will  support  program  development,  docu¬ 
mentation,  tools  development  and  management.  The  system  de¬ 
veloped  should  be  expandable  so  that  the  system  car.  grew  as 
FJISO's  needs  grow.  The  most  promising  candidate  for  this 
type  of  system  is  the  local  area  network  approach.  The  LAN 
technclogy  is  still  fairly  new,  and  it  may  oe  a  few  years 
before  there  are  any  clear  leaders  in  this  field.  In  the 
meantime,  F3S0  should  begin  working  cn  an  overall  develop¬ 
ment  plan  and  begin  acquiring  equipment  that  could  provide 
short  term  aid  and  also  be  rationally  fitted  into  a  LAN  de¬ 
velopment  in  the  future. 


Chapter  4 

PROGHAftSING  EN  VI  RONH  ENT  S  AND  PRODUCTIVITY 

4. i  Introduction 

The  concept  of  programing  environments  is  one  -.hat  is 
just  beginning  to  get  attention  from  researchers  in  produc¬ 
tivity.  The  development  ci  computer  software  _s  still  in  a 
cottage  industry  phase.  It  is  not  unusual  for  a  programmer 
to  have  to  write  tae  code,  keypunch  it  (or  do  the  data  entry 
on  a  terminal),  document  it,  keep  track  of  modules,  inte¬ 
grate  modules,  test  the  modules,  assemble  the  release  pack¬ 
age  and  a  number  of  ether  chores  associated  with  the  pro¬ 
ject.  This  wcuid  be  similar  to  having  an  automotive  worker 
be  the  designer  cf  a  car,  write  the  owner’s  manual,  assemble 
tae  car  and  be  responsible  for  doing  maintenance  work  on  it. 
This  would  require  personnel  who  were  much  more  skilled  than 
current  automotive  service  personnel,  and  cars  would  be  a 
great  deal  more  expensive  as  a  consequence. 

This  problem  that  programming  work  has  is  just  ar.  example 
of  general  problems  in  the  clerical  area.  Capital  expendi¬ 
ture  per  worker  is  lower  for  white  collar  workers  than  for 
any  ether  type.  The  average  per  capita  capital  expenditure 
for  white  collar  workers  in  our  economy  is  $3,000.  The  cor¬ 
responding  figure  for  blue  collar  workers  is  $25,000  and  for 
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farm  workers  is  $35,000.  Froduc tivity  is  harder  to  measure 
in  clerical  areas.  Perhaps  part  of  the  problem  is  that  man¬ 
agers  feel  that  office  workers  are  not  really  producing  any¬ 
thing  anyway,  so  why  spend  any  money  on  them.  This  attitude 
is  crumbling  ir.  the  face  of  office  automation,  but  it  will 
be  a  while  before  it  disappears. 

4.2  ELEHENXS  OF  A  P3QGBAMBING  EHViaOShEHT 

when  we  talk  about  a  programming  environment,  we  are 
talking  about  a  whole  complex  of  support  facilities  for  a 
programmer.  Specifically,  the  points  covered  m  the  idea 
in  ol uds : 

1.  Tools  support  -  access  to  convenient,  up  to  date 

technologies. 

a)  interactive  systems. 

b)  Flexible  data  editing  facilities. 

eg  Text  formatting  and  document  preparation. 

dj'  Electronic  mail. 

e)  Interactive  compilers. 

f)  Flexible  interactive  terminal  systems. 

2.  Architectural  environment. 

a)  Comfortable  workspaces. 

b)  Adequate  storage  for  documentation  and  listings. 

c)  Library  facilities. 

d)  Conference  and  meeting  facilities. 

3.  Team  support. 
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d)  Data  entry  personnel. 

b)  Frcgram  and  data  libararians. 

c)  Technical  writers. 

d)  Management  aides. 

e)  Adequate  secretarial  support. 

4.  Social  support. 

a)  Professional  development  seminars. 

b)  Training  opportunities. 

c)  Access  to  technology. 

The  requirements  cf  a  programmer  in  a  systems  development 
environment  are  basically  threefold.  They  are: 

1.  Privacy  for  proaram  writing  activities. 

2.  Meeting  areas  for  social  interaction  on  project  work. 

3.  System  access  for  pregram  testing. 

Anything  that  undermines  these  requirements  will  undermine 
the  programming  environment  generally. 

4.3  IMPROVEMENTS  IN  PROCOCTIVITT  DOE  TO  IMPROVED 
SMIIIcnhent 

From  FMSO's  point  of  .  iew,  the  most  interesting  question 
is  hew  much  productivity  will  be  improved  by  improving  the 
development  environment.  This  will  be  necessary  for  any 
cost  justification  of  improvement.  It  turns  out  that  this 
will  not  be  an  easy  question  to  answer  for  a  variety  of  rea¬ 
sons.  First  of  all,  there  is  no  real  system  of  productivity 
measurement  in  place  at  FWSO,  so  we  have  no  way  to  measure 
productivity.  Secondly,  FMSO  is  a  unique  environment.  In 
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most  ways,  it  is  far  behind  current  computer  technology, 
is  doing  development  in  a  computer  environment  that  io.it  or¬ 
ganizations  scrapped  ten  years  ago.  Its  management  climate 
is  mere  up  to  data.  The  improved  programming  technologies 
are  given  in  the  development  handbooks,  the  staff  is  aware 
of  them  and  seems  dedicated  to  implementing  those  that  car. 
be  adapted  to  FfiSO' s  situation. 

It  is  this  combination  cf  factors  that  maxes  comparison 
with  industrial  experience  difficult.  .dost  of  the  research 
on  productivity  improvement  dials  with  tr.  -  improved  program¬ 
ming  technologies.  Thera  is  little  work  done  on  a  compari¬ 
son  between  interactive  vs.  oitch  modes  of  program  develop¬ 
ment.  Ihe  reason  for  this  is  simple.  Iveryoody  considers 
interactive  ccdir.o  tc  be  seen  an  improvement  that  no'body  has 
cot.nered  tc  research  the  question  lately.  There  were  a  few 
tentative  papers  on  the  subject  in  the  .ate  19o0's,  but 
there  has  beer,  little  recently*. 

The  pregraumg  styles  cf  tne  workers  will  be  different 
in  interactive  environments  than  they  will  m  a  batch  envi¬ 
ronment.  When  a  programmer  doss  development  work  ir.  a  batch 
mode,  he  has  tc  keep  several  projects  going  concurrently. 

*  ?e  Harold  Sackman's  article,  "Exploratory  Experimental 
Studies  Comparing  Online  and  Offline  Programming  Perform¬ 
ance"  published  in  the  Coma un i cations  of  the  Association 
121  Computing  Machinery  in  January  1963?  "Sackman's  arti¬ 
cle  concluded  that  there  was  about  a  20%  improvement  ir. 
programmer  time  using  an  interactive  system.  It  should  be 
noted  that  study  used  the  relatively  crude  interactive 
systems  cf  the  late  1960's.  Today's  screen  oriented  sys¬ 
tems  are  orders  of  magnitude  better  than  the  early  inter¬ 
active  systems. 
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This  wav,  he  has  something  to  do  while  waiting  for  the 
pat  of  his  last  computer  run.  This  also  means  that  there 
a  setup  cost  each  tame  he  shifts  gears  from  one  project  to 
another.  In  an  interactive  environment,  a  programmer  is 
able  to  concentrate  on  a  single  project  until  it  is  ccmple 
ed.  He  dees  net  have  to  plan  his  work  around  the  difficul 
ties  of  computer  access.  This  would  suggest  that  interac¬ 
tive  systems  develooment  should  have  high  payerf  in  a 
maintenance  oriented  environment  like  FSSO's.  For  most 
maintenance  wer  * ,  the  changes  to  a  program  tend  to  be  s  at  a  1 
and  could  be  completed  quickly.  Ar  interactive  system  cou 
also  be  useful  in  controlling  the  ferns  ar.  i  documentation 
associated  with  program  development. 

4 . 4  COMCIOSICN5 

Acre  attention  needs  tc  be  giver,  to  tne  issue  of  progra 
mmg  environment  at  FMSO.  The  major  points  that  need  im¬ 
provement  are  the  physical  .and  technical  environment .  The 
have  been  amply  covered  elsewhere.  But  simply  improving 
tnese  aspects  of  the  environment  is  not  enough.  «her.  the 
new  system  is  installed,  work  should  also  begin  on  providi 
supper*  no  developers  in  the  form  cf  improved  *ocls,  sec  re 
tarial  assistance  and  general  programming  team  support. 
This  will  allow  FKSO  to  reap  full  benefit  from  -he  -ev  tec 
no lo  gies . 


Chapter  5 

A  PRODUCTIVITY  M EAS  OHEMENT  SYSTEM 

5-  1  INTRODUCTION 

This  chapter  will  discuss  the  measurement  of  productivi 
within  the  software  development  and  maintenance  process. 
Productivity  measures,  when  defined  as  a  measure  cf  output 
divided  by  a  measure  of  input,  are  used  for  measuring  the 
efficiency  cf  any  production  process.  Productivity  measur 
car.  provide  information  on  efficiency  at  all  levels  of  an 
organisation.  These  levels  include  various  projects  and  d 
partmetts ,  as  well  as  the  entire  organisation.  This  chart 
will  examine  the  purposes  cf  productivity  measurement ,  the 
productivity  measurement  problem  in  general,  various  meas¬ 
ures  cf  programming  productivity  and  a  brief  discussion  cf 
the  implementation  of  a  productivity  measurement  system. 

5.2  PURPOSES  OF  PRODUCTIVITY  M EAS U RE MEN I 

The  primary  purpose  for  measuring  productivity  in  the 
software  development  and  maintenance  process  is  to  provide 
information  fcr  use  in  the  three  major  phases  of  software 
management.  These  phases  are  the  planning,  control  and 
evaluation  of  the  entire  software  process  as  well  as  indi¬ 
vidual  projects  within  the  process. 
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5. 2. 1  £lanni£3 

The  primary  function  of  the  planning  phase  of  scf-wara 
management  is  to  provide  a  prior  estimate  of  resources  re¬ 
quired  for  supporting  the  software  development  and  mainte¬ 
nance  process,  either  on  a  project  basis  or  or.  a  recurring 
oasis  for  the  entire  software  department.  The  planning 
phase  allows  for  the  establishment  of  budgets  for  *he  de¬ 
partment  and  projects  as  well  as  subbudgets  for  each  of  the 
input  factors,  especially  labor,  which  are  required  in  the 
software  process.  The  productivity  measure  is  used,  along 
with  an  estimate  of  the  amount  of  output  required  for  the 
project  or  department,  to  generate  an  estimate  of  the  amour, 
of  input (s)  required  for  a  given  tine  period.  It  should  be 
noted  that  there  exists  a  direct  linit  during  this  phase  be¬ 
tween  the  productivity  measure  anl  project  cost  estimating 
methods.  Cn  a  project  basis,  the  productivity  measurement 
problem  is  equivalent  to  the  project  cost  estimation  prob¬ 
lem. 

5.2.2  Control 

The  control  phase  of  software  management  entails  the  de¬ 
termination  of  the  extent  cf  progress  cr  the  software  pro¬ 
cess  and  may  be  applied  at  both  the  department  and  project 
level.  Progress  may  be  measured  on  two  dimensions,  budget 
and  schedule.  On  the  budget  dimension,  actual  «Apenditures 
are  compared  with  planned  expenditures  and  variances  are  ex 
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amir.ed.  Adequacy  of  progress  is  measured  by  these  varianc¬ 
es.  The  planned  expenditures,  which  were  generated  during 
the  planning  phase,  usually  serve  as  the  standards  for  meas 
uring  progress.  However,  the  plans  are  subject  he  acdifica 
ti or.  duo  to  unforeseen  contingencies. 

Or.  the  schedule  diirensicn,  actual  elapsed  trues  are  com¬ 
pared  with  planned  elapsed  tines  and,  again,  variances  are 
examined.  As  in  the  case  cf  budgets,  planned  schedules 
serve  as  standards  except  when  modified  by  unexpected 
events.  Productivity  measures  are  used  in  this  phase  tc  as 
sist  ir.  the  determination  of. actual  budgets  and  schedules, 
as  well  as  tc  assist  in  the  modification  of  plans  when  con¬ 
tingencies  occur. 

5.2.3  Evaluation 

The  evaluation  phase  of  software  management  concerns  it¬ 
self  with  the  determination  of  how  well  the  software  proces 
is  meeting  the  goals  cf  the  organization.  This  determina¬ 
tion  may  be  made  at  the  department  level,  the  project  level 
or  any  intermediate  level.  An  integral  part  of  this  deter¬ 
mination  of  the  adequacy  of  the  entire  process  is  an  evalua 
tion  of  the  efficiency  of  the  process.  Productivity  meas¬ 
ures,  functioning  as  pure  efficiency  measures,  are  useful 
during  the  evaluation  phase. 
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5.3  EIQDO£TIVJSI  mbasprembnt  SJHfiSiL 


Productivity  is  defined  as  the  relationship  between  the 
output  of  goods  and  services  and  the  inputs  used  to  produce 
those  outputs.  Two  general  types  of  productivity  ratios  are 
generally  used:  total  factor  productivity  and  partial  fac¬ 
tor  productivity  ratios.  Total  factor  ratios  include  ail  of 
the  inputs  in  the  production  process,  wnile  partial  factor 
ratios  do  not.  The  inputs  or  factors  of  production  are  gen¬ 
erally  classified  into  three  major  categories:  labor,  capi¬ 
tal  and  materials.  A  total  factor  ratio  may  be  aole  to  dis¬ 
tinguish  subclasses  within  each  of  these  major  categories. 
For  example,  labor  is  net  homogeneous  and  different  types  of 
labor,  such  as  skill  levels,  may  be  appropriate.  Any  factor 
may  be  used  but  labor  is  ir-ccmmcr  usage  as  a  partial  meas¬ 
ure  with  the  input  measure  generally  being  man-hours  or 
man-years.  Ncta  that  the  use  of  partial  measures  may  be 
misleading  since  changes  in  one  input  have  effects  upon  all 
other  inputs  as  well  as  output.  Consequently,  an  increase 
in  output  per  man-year  indicated  by  a  partial  ratio  should 
not  be  interpreted  to  mean  that  the  increase  is  due  solely 
to  the  increased  efficiency  of  labor.  This  is  because  the 
increase  in  output  is  a  result  of  all  of  the  factors  of  pro¬ 
duction  working  together. 

Productivity  ratios  are  affected  by  both  short  and  long- 
run  elements.  Probably  the  most  important  of  the  short-run 
elements  is  the  change  in  utilization  of  productive  capaci- 
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-y.  productivity  ratios  generally  vary  inversely  with 
caanges  in  the  degree  of  capacity  utilization  since  the  fix¬ 
ed  inputs  cannct  be  varied  with  changes  in  output.  Other 
elements  causing  short-run  changes  in  productivity  are  bcth 
the  level  of  effort  and  the  learning  process  which  occur  as 
individuals  adapt  to  new  methods  and  equipment.  Among  those 
elements  causing  long-run  changes  in  productivity  are  chang¬ 
es  in  the  quality  of  inputs.  Such  changes  are  referred  to 
as  input-augmenting  technological  change.  Perhaps  most  im¬ 
portant  of  the  long-run  elements  are  changes  in  the  methods 
of  organizing  production.  These  changes  in  the  underlying 
production  function  a  re  a  result  of  such  items  as  changes  in 
the  organizational  structure  or  changes  in  managerial  abili¬ 
ty- 

There  are  several  problems  involved  in  the  use  of  produc¬ 
tivity  measures.  These  center  around  t.as  measurement  of  in¬ 
puts  and  outputs  and  ‘•heir  abilities  to  measure  efficiency. 
When  measuring  inputs  for  use  in  a  productivity  measure,  it 
is  desirable  tc  ensure  that  only  the  inputs  that  are  actual¬ 
ly  utilized  in  the  production  process  are  used  in  the  meas¬ 
ure.  This  is  especially  important  for  the  xabor  input  and 
implies,  for  example,  that  only  time  worked  should  be  uti¬ 
lized  in  the  measure  instead  of  time  paid.  Although  time 
paid  may  be  of  interest  since  it  corresponds  to  the  total 
cost  incurred,  it  is  important  that  such  items  as  adminis¬ 
trative  time,  etc.  be  separated  out.  This  will  enable  man- 


agers  to  fccus  mere  carefully  upon  the  seoarate  activi-ies 
of  productive  work  and  other  work.  Ms?,  it  is  imperative 
that  only  inputs  which  are  homogeneous  be  aggregated.  Using 
labor  as  an  example  again,  different  skill  levels,  such  as  a 
keypunch  operator  versus  a  systems  programmer,  perform  en¬ 
tirely  different  tasks  and  should  be  aggregated  only  when 
they  are  occur  within  a  particular  department.  It  is  also 
preferable  to  measure  inputs  in  terms  of  physical  units. 
Value  units  may  also  be  utilized  but  physical  units  should 
be  used  if  availarle. 

A  primary  problem  with  the  measurement  of  outputs  is  that 
convenient  measures  are  sometimes  not  available  either  in 
physical  units  or  value  units.  This  output  measurement 
problem  occurs  principally  within  public  sector  organiza¬ 
tions.  In  this  case,  there  is  usually  no  accepted  opera¬ 
tional  definition  of  what  the  outputs  really  are  (national 
defense,  welfare,  etc.),  and  the  outputs  are  not  traded  in 
any  markets  so  that  value  measures  are  unavailable,  also. 
Consequently,  most  of  the  output  measures  in  use  are  actual¬ 
ly  intermediate  outputs  or,  simply,  inputs  to  further  pro¬ 
cesses.  Such  measures  are  weak,  at  best. 

In  the  cases  where  inputs  and  outputs  may  not  be  precise¬ 
ly  measured,  the  productivity  measure  becomes  susceptible  to 
perverse  incentives  and  gaming.  This  implies  that  the  con¬ 
trol  and  evaluation  phases  of  management  may  focus  upon 
faulty  indicators.  For  example,  if  the  output  measure  is 
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not  truly  output,  there  is  some  danger  that  generation  of 
input  may  be  encouraged  rather  than  output.  This  increase 
in  inputs  does  not  necessarily  imply  increased  output. 

Also,  use  of  such  measures  may  provoke  the  generation  of 
useless  output.  In  one  instance  in  the  public  sector,  the 
measure  was  square  feet  of  buildings  cleaned.  This  resulted 
in  many  areas  being  cleaned  twice  daily  and  some  areas  not 
at  all. 

Another  major  problem  with  productivity  measures  is  how 
to  deal  with  the  quality  of  output.  Ostensibly,  the  quality 
of  output  should  be  held  constant  in  productivity  measures 
but  changes  in  quality  may  be  difficult  to  measure.  Quality 
changes  can  cause  difficulties  in  both  directions;  quality 
deterioration  may  cause  the  measure  to  increase,  while  qual¬ 
ity  improvement  may  cause  the  measure  to  decrease. 

A  final  problem  is  that  changes  in  one  partial  productiv¬ 
ity  measure  can  be  misleading  concerning  its  effects  upcn 
the  entire  production  process.  There  are  numerous  ways  to 
obtain  a  given  output  with  several  inputs.  Technical  effi¬ 
ciency  exists  when,  at  a  constant  output  level,  reduction  of 
one  input  necessitates  an  increase  in  another  input.  How¬ 
ever,  economic  efficiency  exists  when  the  relative  marginal 
costs  of  utilizing  ail  inputs  in  production  of  the  output 
are  the  same.  Technical  efficiency  is  required  for  economic 
efficiency  but  not  vice  versa.  Note  that  neither  of  these 
two  concepts  of  efficiency  are  captured  oy  partial  produc- 


tivity  measures.  Overdepender.ee  upon  partial  measures  for 
control  and  evaluation  can  result  in  underutilization  cf 
particular  inputs  which  leads  to  less  rather  than  more  effi 
cient  use  cf  resources. 


5. 4  MEASURING  PROG  R  AMMING  PROD  OCTIVITY 
5.4.1  Introduction 

Keeping  in  mind  the  above  discussion  of  productivity 
measures  in  general,  we  can  now  begin  to  discuss  the  soft¬ 
ware  programming  productivity  problem.  Programming  is  or.s 
of  the  major  inputs  into  the  software  development  and  main¬ 
tenance  process.  Note,  however,  that  programming  is  an  in¬ 
put  to  this  process;  it  is  not  the  output.  The  output  of 
the  software  process  is  usable  software.  Other  definitions 
ar.d  measures  of  this  output  abound  but  all  are  simply  fur¬ 
ther  derivations  or.  this  cr.e  concept.  dost  output  measures 
which  are  currently  being  used  in  programming  productivity 
suffer  from  being  either  pure  or  intermediate  inputs.  Phys 
ical  measures,  such  as  programs,  do  not  address  the  problem 
that  users  cf  software  are  not  interested  in  programs  but 
are  interested  only  in  the  output  from  the  programs.  Value 
measures,  such  as  revenues  and  sales,  are  available  for  pri 
vate  sector  entities  but  are  not  available  for  public  secto 
organizations,  such  as  FMSO.  Because  the  definition  of  the 
output  fro*  the  software  process  is  so  equivocal,  several 
alternative  measures  are  being  utilized  currently.  These 
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generally  cluster  arcund  lines  of  code  produced  in  the  pro¬ 
gramming  process,  functions  which  the  program  performs  ar.d 
functions  which  the  user  performs  when  utilizing  the  pro¬ 
gram.  Additionally,  most  variations  cn  these  measures  use 
some  measure  of  labor  to  generate  a  (partial)  productivity 
measure.  Productivity  measures  using  these  three  major 
types  of  output  measures  as  well  as  an  additional  one,  com¬ 
pleted  projects,  are  evaluated  below. 

5.4.2  Lines  cf  Code 

The  productivity  measure  using  lines  cf  code  is  usually 
lines  of  coda  per  labor  unit,  where  the  labor  unit  may  he 
man-days,  man-weeks,  man- months,  etc.  Lines  of  code  is  a 
physical  measure;  however,  it  measures  an  input  into  the 
software  development  and  maintenance  process  not  an  output. 
Lines  cf  cede  are  necessary  to  produce  a  software  program 
but  cannot  measure  hew  the  program  functions. 

A  major  difficulty  in  implementing  the  use  of  lines  of 
code  as  a  productivity  measure  is  to  define  exactly  what  a 
line  consists  cf.  Programs  consist  of  more  than  executable 
lines  of  code.  In  addition  to  the  execucabie  statements, 
there  may  be  jcb  control  language,  comment  statements,  data 
declarations  and  macro-instructions.  Depending  upon  what  i 
or  is  not  counted  as  a  line,  various  measures  of  lines  of 
code  may  differ  by  factors  of  two  or  more. 
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Another  irajcr  difficulty  in  using  lines  of  code  as  a 
measure  concerns  its  poor  capabilities  when  measuring  non¬ 
coding  tasks.  The  entire  program  development  process  re¬ 
quires  much  more  than  coding.  Most  lines-of-code  measures 
attempt  to  deal  with  this  by  using  long-run  measures  which 
have  some  average  amount  cf  nonceding  work  built  into  them. 
However,  the  application  cf  lines  cf  code  per  programmer- 
month  to  such  tasks  may  result  in  questionable  results  in 
specific  circumstance s. 

These  measures  also  tend  to  penalize  higher  level  lan¬ 
guages.  The  initial  portions  of  the  software  development 
cycle,  such  as  the  determination  of  user  requirements,  spec¬ 
ifications  and  test  cases,  as  well  as  later  portions,  such 
as  the  writing  of  documentation,  do  net  depend  upon  the  lan¬ 
guage  utilized.  Since  higher  level  languages  tend  to  re¬ 
quire  fewer  source  statements  to  program  than  lower  level 
languages,  combination  of  the  coding  portion  with  the  lan¬ 
guage-independent  portions  of  development  results  in  an  ap¬ 
parent  lesser  productivity  when  using  higher  level  languag¬ 
es.  This  apparent  paradox  exists  because  the  productivity 
measure  is  just  that  and  is  not  a  measure  of  total  cost. 

A  problem  related  to  the  higher  level  language  problem  is 
that  lines  cf  code  does  net  adequately  deal  with  quality 
differentials  in  different  pregrams.  Some  efforts  have  been 
made  to  permit  the  introduction  of  quality  measures  within 
lines  of  code  via  the  use  of  complexity  metrics.  Because 
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the  field  cf  complexity  aetrics  is  still  undergoing  develop¬ 
ment  with  no  dominant  metric  available,  the  use  of  such  me¬ 
trics  has  nor  yet  offered  a  precise  solution  to  the  quality 
measurement  problem. 

The  last  major  problem  with  lines  of  code  is  that  it  per¬ 
petuates  the  myth  that  coding  is  the  predominant  activity  in 
software  development  and  maintenance.  This  may  have  been 
the  case  in  the  early  days  of  programming,  but  in,  for  exam¬ 
ple,  modular  programming  there  may  be  no  new  code  created 
during  a  particular  project. 

A  relatively  minor  problem  appears  to  be  that,  when  such 
measures  are  applied  ~o  subtasks  in  a  project  and  then  ag¬ 
gregated,  the  aggregation  cf  the  subtask  measures  to  a  sin¬ 
gle  overall  measure  is  performed  incorrectly.  The  correct 
method  of  aggregation  depends  upon  whetner  the  suotasks  are 
performed  simultaneously  cr  sequentially.  If  they  are  per¬ 
formed  simultaneously ,  the  aggregate  measure  will  be  larger 
than  any  of  the  subtask  measures,  and,  if  they  are  performed 
sequentially,  the  aggregate  measure  will  be  smaller  than  any 
of  the  sufctask  measures.  Combinations  require  that  sequen¬ 
tial  subtask  measures  be  aggregated  first,  followed  by  ag¬ 
gregation  of  the  remaining  simultaneous  measures. 

As  with  all  productivity  measures,  lines  of  code  is  sus¬ 
ceptible  tc  gaming.  Programmers  may  be  able  to  generate  ap¬ 
parent  increases  in  productivity  where  none  really  exists  as 
wall  as  apparently  prevent  decreases  in  productivity  where 
such  a  decrease  has  actually  occurred. 


Despite  the  problems  given  above,  lines  of  code  does  have 
a  major  advantage  in  that  it  is  relatively  easy  to  measure. 
With  judicious  use,  lines  cf  code  nay  offer  an  excellent 
method  for  measuring  programmer  productivity.  The  following 
statement  illustrates  this: 


There  is  still  a  great  deal  tc  be  learned  about 
guality  and  productivity  normalized  against  lines 
cf  code.  We  have  not  explored  the  limits  of 
knowledge,  and  comparisons  between  different  kinds 
cf  programs — wi* h  lines  of  code  counted  the  same 
way  for  both — almost  daily  yield  new  insights  and 
discoveries.  It  is  premature  to  soar,  ion  this 
method,  just  when  results  are  becctin ;  encourag¬ 
ing.  5 


5.4.3  Program  Pune t ions 

A  productivity  measure  has  been  proposed  and  tested  which 
is  based  upon  functions  performed  by  tne  program.  The  spe¬ 
cific  measure  is  laoor  units  (specifically,  man-hours)  per 
function.  Note  that  this  is  not  actually  a  productivity 
measur3,  but  is  the  inverse  of  a  productivity  measure.  As 
in  the  case  of  lines  cf  cede,  program  functions  measures  an 
input  into  the  software  development  and  maintenance  process 
instead  of  an  output.  Although  it  is  aole  to  measure  how  a 
program  functions,  this  measure  does  not  capture  how  users 
evaluate  or  utilize  a  particular  piece  of  software. 


5  This  quote  (page  51)  and  some  of  the  above  discussion  is 
taken  from  Jones,  T.C.,  "Measuring  Programming  Quality  and 
Productivity,"  J3M  Systems  Jou  rnal,  Voi.  17,  no.  1,  1978, 
pp .  39-63. 


Perhaps  the  most  difficult  aspect  cf  using  program 


functions  as  a  measure  is  the  definition  of  a  program  func¬ 
tion.  Prior  applications  have  beer,  limited  to  struct ur si 
programming  environments  only.  Within  this  structured  ap¬ 
proach  a  function  is  defined  to  be  a  paragraph.  Depending 
upon  the  particular  language,  a  paragraph  and,  therefore,  a 
function  may  be  a  procedure  or  a  (sub) routine .  This  also 
corresponds  to  the  concept  of  a  module.  Given  a  specific 
method  of  measuring  program  functions,  this  measure  is  rela- 
*ively  easy  tc  calculate.  However,  this  measure  is  also 
susceptible  to  gaming,  depending  upon  the  extent  tc  which 
the  individual  programmer  car.  control  tae  structure  of  the 
program. * 

5.4.4  User  Functions 

A  productivity  measure  has  been  proposed  which  is  oased 
upon  external  attributes  or  functions  which  are  activated  b v 
the  user.  The  general  approach  in  this  case  is  .to  determine 
the  external  or  user-oriented  manifestations  cf  any  applica¬ 
tion  software.  In  practice,  this  is  accoaplisned  by  count¬ 
ing  the  number  of  external  user  inputs,  outputs,  inquiries 
and  master  files  ielivered  by  the  project. 


*  A  discussion  of  program  functions  may  be  found  in  Cross¬ 
man,  T.D.,  "Taxing  the  Measure  of  Programmer  Productivi¬ 
ty*”  p^taaatior. .  Say  19  79,  pp.  144-  147. 
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The  counts  cf  each  of  these  four  factors  say  be  weights 


to  attempt  to  reflect  the  relative  value  of  each  t  the 
user.  Albrecht  suggests  specific  weights  which  were  found 
to  be  useful  in  one  particular  organization.  Additionally, 
the  weighted  sum  may  be  adjusted  to  account  for  extraordi¬ 
nary  circumstances.  The  result  is  a  measure  cf  function 
counts  for  a  specific  project.  The  actual  measure  utilized 
by  Albrecht  was  hours  worked  per  function  count,  which  is 
the  inverse  cf  a  productivity  measure. 

The  measure  of  user  functions  per  laoor  unit  offers  the 
considerable  advantage  of  actually  attempting  to  measure  the 
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accve.  Since  it  is  more  outp ut- oriented,  it  is  much  more 
difficult  tc  gare  'nan  any  cf  the  ether  measures. 

The  actual  measurement  of  user  functions  in  specific  cir¬ 
cumstances  may  be  ncn.'.rivial,  however.  For  example,  it  is 
conceivable  that  one  nay  have  a  difficult  time  discerning 
whether  a  particular  function  is  ar.  input  or  an  inquiry.  If 
a  different  weight  is  allowed  fer  inputs  than  is  allowed  for 
inquiries,  toe  selection  cf  particular  user  functions  may 
have  ar.  unintended  effect  upon  the  actual  value  generated  by 
the  measurement  procedure.7 


7  User  functions  are  discussed  in  Albrecr,  A.J.,  "Measuring 
Application  Development  Productivity,"  Proceedings  of  the 
SH ABE^GU IDE^J3M  Application  Development  S^agcsium,  October 
19797  pp7~33-92.”  ' 
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5.4.5  £25PiSi§i  Projects 

Another  possible  measure  is  completed  projects  per  labor 
unit.  This  measure  offers  the  advantage  of  being  exception 
ally  easy  to  inclement  and  use.  However,  unless  a  reason¬ 
ably  large  number  of  different  categories  of  projects  are 
maintained,  this  measure  is  also  exceptionally  susceptible 
to  gaming.  This  is  especially  true  if  the  individual  to  be 
measured  has  any  input  into  the  selection  of  which  projects 
are  tc  be  programmed  by  whom.  Also,  the  existence  of  a 
large  number  of  categories  compromises  the  ease-o:  -e  ad¬ 
vantage  of  this  measure.  Similarly,  it  presents  the  addi¬ 
tional  problem  of  cross  comparisons  of  different  measures 
when  locking  at  a  single  programmer. 

5.4.6  Summary 

Each  of  the  above  measures  has  unique  advantages  and  dis 
advantages.  This  ensures  that  there  is  no  one  dominant 
measure  for  all  situations.  Since  rHSO  is  noth  a  develop¬ 
ment  and  a  maintenance  activity,  these  measures  must  be  ex¬ 
amined  for  their  specific  comparative  advantages  in  the  de¬ 
velopment  and/or  maintenance  processes.  Along  this 
dimension,  the  two  functional  measures,  program  functions 
and  user  functions,  are  useful  primarily  in  the  development 
process.  The  ether  two  measures,  lines  of  code  and  complet 
ed  projects,  may  be  used  for  both  development  and  mainte¬ 
nance.  The  measures  also  have  relative  advantages  and  dis- 
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advantages  when  used  in  either  applications  or  systems 
programming  projects.  Note,  additionally,  that  there  are 
difficulties  in  making  comparisons  across  different  lar.guaa 
es  or  organizations  but  here  we  are  interested  only  in  aeas 
uring  the  productivity  of  the  programming  process  within 
f  M  50  . 

Hence,  it  is  suggested  that  a  pilot  project  be  set  up  to 
collect  data  or.  a  number  cf  software  projects  and  that  sev¬ 
eral  measures  be  evaluated  using  these  data.  This  would  re 
suit  ir.  two  or  possibly  three  measures  being  selected  for 
further  testing  on  a  much  larger  sample.  After  a  reascnabl 
number  of  projects  have  been  examined,  then  the  measures  aa 
be  further  evaluated  to  produce  an  op  =  ratior.al  productivity 
measurement  system. 

5.5  IMPLEMENTATION  OF  A  PRODUCTIVITY  MEASUREMENT  SYSTEM 

Productivity  measurement  systems,  despite  tne  advantages 
discussed  above,  are  not  used  universally.  Perhaps  the  ma¬ 
jor  reason  for  this  is  because  these  systems  are  not  cost¬ 
less.  Resources  .are  required,  from  both  managers  and  pro¬ 
grammers,  ir.  crder  to  implement  such  systems.  All  of  the 
measurement  systems  above  are  based  on  daily  inputs  by  ir.di 
vidual  programmers  in  order  to  keep  track  of  labor  units. 
Also,  analysis  of  the  project  is  necessary  m  order  to  gen¬ 
erate  alternative  output  measures.  However,  such  systems 
are,  in  general,  cost-effective  based  upon  their  general  us 
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age.  In  addition  to  the  measure Bent  system's  contribution 
to  the  potential  increase  in  productivity,  there  are  several 
other  reasons  that  FhSO  should  begin  to  implement  a  produc¬ 
tivity  measurement  system. 

The  major  reason  is  that  a  similar  system,  designed  to 
associate  specific  resources  with  specific  software  pro¬ 
jects,  will  be  implemented  in  the  near  future  by  DOO.  The 
Air  Force  is  the  lead  service  in  the  testing  of  the  Software 
Acquisition  Resource  Expenditure  (SARE)  reporting  system. 

New  directives  will  require  such  reports  for  all  software 
developed  by  and  for  DOD.  Consequently,  the  forthcoming 
SARE  reporting  system  will  be  much  easier  to  implement  if  a 
data  collection  system  has  been  tested  and  is  being  utilized 
by  FMSO. 

Another  possible  reason  for  movement  to  a  productivity 
measurement  system  by  FMSO  is  to  provide  the  basis  for  quan¬ 
titative  justification  of  resources  required  for  particular 
projects.  Under  the  commercial  activities  program,  all 
to n- mission-essential  activities  are  subject  to  private  sec¬ 
tor  provision.  In  the  case  of  software  development  and 
maintenance,  this  program  would  require  FMSO  to  bid  on  par¬ 
ticular  projects  along  with  private  sector  software  houses. 
Such  bids  must  be  auditable,  which  implies  that  productivity 
information  must  be  quantitatively-based  and  verifiable.  A 
related  aspect  is  that  the  NARDAC’s  are  moving  to  a  NIF 
funding  basis  instead  of  a  mission-funded  basis.  It  is  not 
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impossible  that  FMSO  and  its  customers  could  be  moved  no 
such  a  fund  accounting  basis  in  the  future. 

Although  a  productivity  measurement  system  can  provide 
reasonably  precise  and  accurate  information,  it  cannot  in¬ 
crease  productivity  on  its  own.  Otner  chapters  of  this  re¬ 
port  provide  other  techniques  and  methods  for  dealing  with 
productivity  enhancement  at  ?3SO.  As  ms  following  remark 
indicates,  these  other  factors  are  also  important. 


Hew  workers  feel  about  their  jobs,  about  their 
fellow  workers,  about  management,  and  aocut  the 
organization,  may  oe  more  important  1:1  influencing 
productivity  than  is  the  particular  way  they  are 
instructed  to  do  their  work,  the  formal  organiza¬ 
tional  structure,  or  ever,  financial  incentives. 9 


•  This  is  found  on  page  1038  of  Nelson,  8.3.,  "Research  on 
Productivity  Growth  and  Productivity  Differences:  Dead 
Ends  and  New  Departures,"  The  Journal  of  Economic  Lit^ya- 
HIS#  Tol.  19,  No.  3,  September  1981,  pp.  1029-10647” 
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chapter  6 

1  PROJECT  PLANNING  STSIEH 

6.1  INTRODUCTION 

Software  project  a  aa  a  gen-act  has  never  been  an  easy  task. 
The  area  is  characterised  by  slipped  schedules,  overdue  de¬ 
liveries  and  systems  that  do  not  work  as  they  were  intended. 
Over  the  years,  we  have  gotten  smarter  about  software  system 
development.  We  knew  more  about  hew  to  do  it,  and  we  settle 
for  less  than  our  nest  optimistic  hopes.  A  manager  thrown 
info  this  environment  for  the  first  time  guickly  comes  to 
appreciate  Fred  Brooks  metaphorical  use  of  the  LaBrsa  Tar 
Pits  to  characterize  software  development  projects9- 

A  great  deal  has  been  writt-n  about  software  project  man¬ 
agement  techniques  lately.  Naturally,  most  of  the  writeups 
are  cf  success  stories.  In  the  normal  manner  of  success 
stories,  they  make  the  project  management  process  seem  easi¬ 
er  than  it  probably  was.  This  is  where  the  "Grass  is  Green¬ 
er"  syndrome  begins  to  come  in.  We  know  that  in  our  own  or¬ 
ganizations,  there  are  problems  that  sometimes  get  out  of 
hand.  These  success  stories  sometimes  make  us  think  that 
everybody  else  has  things  under  control.  The  answer  then 
seems  to  be  to  taka  the  methods  that  hav9  (presumably) 


9  Fred  Brooks,  The  fllliiisal  Nan- month ,  p.  3. 
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worked  wall  elsewhere  and  adapt  then  to  our  organizations. 

This  would  be  a  great  idea  if  it  were  possible,  but  un¬ 
fortunately,  there  are  a  few  hitches  in  the  process.  Soft¬ 
ware  projects  are  not  simple,  and  they  are  not  standardized 
across  organizations.  The  standards  for  measuring  produc¬ 
tivity  in  different  organizations  are  going  to  be  vastly 
different.  We  can  laarn  a  lot  about  installing  a  project 
planning  and  control  system  by  observing  the  techniques  that 
have  worked  elsewhere,  but  we  have  to  be  careful.  It  is  es¬ 
pecially  dangerous  to  take  productivity  figarss  from  cr.s  or¬ 
ganization  as  necessarily  being  indicative  of  what  we  car. 
expect.  First  of  all,  we  have  to  know  what  they  think  dio- 
ductivity  is  and  how  they  account  for  it.  That  information 
rarely  appears  in  the  articles  in  sufficient  detail  to  allow 
us  to  reconstruct  the  measures  used  by  the  original  re¬ 
searchers,  much  less  use  them  in  our  own  organizations. 

What  we  wall  have  to  do  is  to  develop  our  own  models 
(probably  patterned  on  these  developed  elsewhere),  gather 
data  cr.  how  they  work,  and  gradually  develop  our  own  system 
for  project  estimating.  This  implies  that  a  project  estima¬ 
tion  model  has  to  be  tailer  made  for  a  given  organization. 
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6.2  E£2jJ1CT  PLANNING  £»£  gONTHOJ.  SISTgaS 


Just  because  project  planning  and  control  systems  must  be 
tailored  to  a  giver,  organization,  this  does  not  mean  that 
there  is  net  considerable  guidance  available  on  successful 
approaches  to  project  planning  systems.  There  are  two  major 
approaches  we  would  recommend  considering  as  models  for  a 
project  planning  system  at  FM30.  The  first  of  these  is  the 
SLIM  system  developed  by  Lawrence  Eutnam10.  Putnam's  model 
is  based  on  the  Rayleigh  Curve  and  can  be  used  to  estimate 
effort  required  and  timing  of  effort  for  medium  to  large 
scale  software  projects.  The  SLIM  model  is  available  over 
time  sharing  services  and  could  serve  as  a  useful  first  ap¬ 
proach  to  developing  local  project  planning  models  at  FMSO. 

A  goed  source  for  information  on  the  SLIM  model  and  the  way 
in  which  it  is  used  for  project  planning  is  given  by  Vor- 
gar.g1*.  The  SLIM  model  is  basically  a  macro  approach  to 
cost  and  effort  estimation  that  makes  reasonable  assumptions 
about  the  type  of  work  being  done.  It  seems  to  offer  a  lit¬ 
tle  less  flexibility  than  you  would  get  by  developing  your 
own  model,  but  it  is  probably  a  good  place  to  start  investi¬ 
gating  the  subject. 


10  A  detailad  account  of  Eutnam' s  model  is  found  in  Lawrence 
Putnam,  "A  General  Empirical  Solution  to  the  Macro  Soft¬ 
ware  Sizing  and  Estimating  Problem",  £EEE  Transactions  op. 
Softwa,r$  S&2inSa£i-12*  July  1978,  pp.  345  -  361. 

**  Blair  Roland  Vorgang,  "A  Macro  Approach  to  Software  Re¬ 
source  Estimation  and  Life  Cycle  Control",  Master's  The¬ 
sis  in  Computer  Systems  Management,  Naval  Postgraduate 
School,  December  1981. 
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The  next  prelect  planning  model  is  t.ne  COCOMO  (for 
constructive  cost  NOdel)  system  developed  by  Barry  3cehm12 
of  TBS.  Bcehm  provides  a  detailed  description  of  the  COCOMC 
system  in  his  bock.  The  data  used  to  derive  the  model  comes 
from  experience  in  software  deve lopmen*  at  TRW.  Unfortu¬ 
nately,  this  experience  aay  not  te  entirely  relevant  to 
FMSO's  softv.’-e  aevel  ODmer.t  situation.  There  is  not  a  suf¬ 
ficient  number  of  COBOL  data  points  used  to  derive  the  pa¬ 
rameters  of  the  model.  The  COCOMC  model  trobaoly  works  bet¬ 
ter  in  the  scientific  computing  environment  common  in  the 
aerospace  industry  tnan  it  does  in  a  purely  lata  prtcessir.g 
environment. 

However,  Boehm  is  detailed  enough  about  how  the  models 
are  put  together  that  he  provides  an  excellent  pattern  to 
follow  in  developing  your  own  project  planning  systems.  The 
COCOMO  system  is  divided  into  basic  and  intermediate  models. 
Both  systems  are  used  to  predict  the  effort  required  to  de¬ 
velop  a  software  product.  The  basic  system  uses  a  single 
predictor  variable,  number  cf  lines  of  source  cods  required, 
and  three  different  modes  cf  development.  The  three  modes 
are: 

Organic  Mode  -  In  organic  mode,  relatively  small 
software  teams  develop  software  in  a  highly 
familiar, in-house  environment.  Most  people 
connected  with  the  project  have  extensive  ex¬ 
perience  in  working  with  related  systems 


12  The  COCOMO  model  as  well  as  a  number  of  other  important 
issues  in  project  planning  and  cost  estimation  are  de¬ 
scribed  in  Barry  Boehm,  Software  Engineering  Economics, 
published  by  Pre  nt  ice- Hall ,  Inc.,  1981. 
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within  the  organization,  and  have  a  thorough 
understanding 'of  how  the  system  under  devel¬ 
opment  will  contributed  to  the  organization's 
objectives. 


Embedded  Mode  -  In  embedded  mode,  the  distinguish¬ 
ing  factor  of  a  project  is  a  need  tc  operate 
within  tight  co r.strain  ts.  The  product  must 
operate  within  (is  embedded  in)  a  strongly 
coupled  complex  of  hardware,  software,  regu¬ 
lations  and  operational  procedures,  such  as 
an  electronic  funds  transfer  system  or  an  air 
traffic  control  system. 


Semidetached  Mode  -  The  semidetached  mode  is  an 
intermediate  level  cetween  the  organic  and 
embedded  modes.  The  project  contains  mix¬ 
tures  of  both  embedded  ar.d  organic  mode  char¬ 
acteristics  . 


FSMC's  mode  of  project  developemer.t  could  normally  be  char¬ 
acterized  as  organic  mode,  although  some  of  the  projects  ur 
iertaken  by  the  Environmental  3rcup  would  probably  be  con¬ 
sidered  to  be  embedded  mo '€. 

At  this  basic  level,  Boehm  reports  that  CCCOMO  pre¬ 
dictions  come  within  a  factor  of  1.3  of  actuals  29%  of  the 
time  ar.d  within  2.3  of  actuals  6  0%  of  the  time.  If  these 
results  do  not  seem  overly  impressive  you  can  move  to  what 
Boehm  calls  intermediate  CCCOHO.  in  this  enhancement  of  th 
model,  Boehm  adds  an  additional  fifteen  factors  or  "cost 
driver  attributes"  that  are  givan  below.  The  names  cf  the 
variables  are  those  used  in  Bchem's  modal  itself. 

Product  Attributes 

RELY  -  required  software  reliability 


DATA  -  data  base  size 
CP  LX  -  product  complexity 

Computer  Attributes 

TIME  -  execution  time  constraint 
STCR  -  main  storage  constraint 
VIST  -  virtual  machine  volatility 
TURN  -  computer  turnaround  tine 


Personnel 


ACAP  - 
A  EXP  - 
PC  AP  - 
VEX?  - 
LEX?  - 


A  ttrib  utes 
analyst  capability 
applications  experience 
programmer  capability 
virtual  machine  experience 
?rcg  ramming  language  ex  per 


er.c  e 


Project  Attributes 

dOCP  -  modern  programming  practices 

TOOL  -  use  cf  software  tools 

SCED  -  required  development  schedule 


Each  cf  these  parameters  are  assigned  weights  (called  "ef¬ 
fort  multipliers"  by  Boehm),  and  these  weights  are  used  mui- 
tiplicativly  to  adjust  parameters  in  the  model.  Boehm 
claims  that  with  intermediate  COCONO,  he  is  within  20%  of 
actuals  68%  of  the  time. 
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In  many  ways,  the  type  of  data  collected  fcv  Bc-eba  for  i n- 
termediate  CGCCMO  is  similar  to  that  already  considered  by 
FM  SO  for  its  own  project  estimation  data  Catherine.  This  ns 
not  s ur pr i sir. g  since  Boehm's  model  passes  what  could  be 
called  a  "reasonable  man"  test.  The  parameters  in  the  model 
are  those  that  an  experienced  professional  would  probably 
expect  to  find  contributing  to  effort  required  in  a  software 
development  project.  With  Boehm's  model,  or  any  software 
development  model,  one  must  be  careful  how  it  is  applied. 

The  development  or  such  an  estimation  model  is  an  evolution¬ 
ary  process  and  there  are  many  opportunities-  for  problems. 
Putnam  cautions  that  "I  have  found  that  manpower  data  accu¬ 
mulated  to  a  yearly  value  is  not  mere  accurate  than  ♦/- 
13-15*  of  the  reported  value.  If  the  data  are  examined  at 
shorter  intervals,  the  percentage  variation  tends  to  be  ever. 
greater"13.  I*  will  take  time  to  figure  out  what  the  bias 
caused  by  accounting  problems  is  in  your  organization  and 
how  these  should  be  accounted  for  in  the  model.  In  addi¬ 
tion,  -here  is  probably  a  "Hawthorne  Effect"  present  in 
software  management.  As  a  model  is  developed,  the  tighter 
controls  are  likely  tc  bring  about  increased  programmer 
awareness  cf  management  goals.  To  a  certain  extent,  the  ef¬ 
fort  projections  may  become  self  fulfilling  prophecies. 

They  determine  the  time  allotad  tc  the  software  project,  and 


n  Lawrence  Putnam,  "A  General  Empirical  Solution  to  the 
Macro  Software  Sizing  and  Estimating  Problem",  IEEE 
Transactions  oji  Saaia££Sia£»  July  1978,  p“3ft6. 


at  the  end  of  than  time,  the  project  is  declared  done  unless 
it  has  truly  major  deficiencies. 

Whatever  model  is  used  for  projections  in  the  F MS 0  envi¬ 
ronment,  it  should  be  kept  in  mind  that  software  effort  es¬ 
timation  :s  net  an  exact  science  by  any  means.  Ihe  models 
will  have  to  ts  developed  in  an  evolutionary  fashion  ar.d 
will  have  tc  be  geared  to  FMSO’s  unique  situation,  .■'ore- 
over,  as  technology  changes  (assuming,  for  example,  that  the 
re ccmmenda tier,  to  acquire  a  development  tools  machine  is 
taxer),  then  it  is  to  be  expected  that  it  wall  be  necessary 
to  change  the  models  used  as  well.  It  wall  probably  take  a 
number  of  years  tc  coma  up  with  a  useful  model. 

6 . 3  CONCLUSIONS 

FMSO  should  begin  some  preliminary  work  on  developing  a 
project  planning  and  effort  estimation  model.  Seme  of  the 
work  has  already  beer.  don<=  in  that  there  has  beer,  data  gath¬ 
ering  done  on  the  time  required  for  projects,  and  the  forms 
used  are  similar  to  those  in  use  elsewhere.  The  next  step 
wall  he  to  analyze  the  data  collected,  to  begin  to  develop 
some  computer  models  cf  effort  and  then  attempt  to  validate 
these  models  cn  cn-going  FKSO  software  development  projects. 
This  work  need  not  wait  until  the  acquisition  of  a  develop¬ 
ment  tools  system.  It  could  probably  be  initiated  using  any 
of  the  micros  currently  in  place  at  Ffiso. 
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